Suite à un message sur la liste de Pause Java concernant des problèmes de securité en Java, je me suis plongé dans le code indiqué. Un certain Mark D. Ladue (mladue@mindspring.com) a publié une série d'applets et d'applications dites hostiles en faisant un état des lieux assez catastrophique de la sécurité en Java. Vous pourrez les trouver à : http://www.cigital.com/hostile-applets
Applets hostiles
J'y ai donc regardé d'un peu plus près et il s'est avéré que la plupart de ces applets hostiles se contentent de saturer les ressources machines, ce qui se rapproche plus du bug que d'un véritable problème de sécurité !
Les applets suivantes entrent dans ce cadre :
- NoisyBear.java : affiche un "ours stupide" et joue un son qu'on ne peut arrêter qu'en sortant du navigateur.
- Wasteful.java : se contente de saturer le processeur en calculant la suite de fibonacci.
- Consume.java : sature le processeur et la mémoire.
-
HostileThreads.java
AttackThread.java tente de saturer la machine en créant une quantité de threads. Lorsque une exception OutOfMemory arrive, lance la création de fenêtres visant à saturer l'affichage (cf. TripleThreat.java). - TripleThreat.java : ouvre des fenêtres noires qui couvrent l'écran, et joue un son pas très agréable.
- DoubleTrouble.java : idem TripleThreat sans le son.
L'applet suivante présente un problème plus sérieux : comme une frame provenant d'une applet est identifiée par un message en bas de la fenêtre, l'astuce consiste à l'agrandir et à la décaler afin d'envoyer cet avertissement en dehors de l'écran.
L'applet affiche ensuite des messages d'erreurs, puis une fenêtre demandant login et password. Ce qui réduit l'intérêt d'un telle attaque est l'impossibilité de présenter correctement cette fenêtre pour qu'elle soit réaliste sur n'importe quel système. Une solution pourrait être d'empêcher les frames de dépasser la taille de l'écran.
Calculator présente un autre problème intéressant : le piratage de puissance processeur. En effet, rien n'empêche une applet d'exécuter un calcul pour le compte du serveur... Cela ouvre certaines perspectives pour le craquage des clés. Il n'y a pas vraiment de moyens d'empêcher ce genre de pratiques.
PenPal utilise son droit de connexion sur le serveur pour envoyer un mail sans prévenir l'utilisateur. D'après l'auteur, on obtient le nom de l'utilisateur, mais lors de mes tests ce n'était pas le cas. Cela dépend peut-être du sendmail utilisé. Il doit par contre être possible d'envoyer le nom et l'adresse IP de la machine cliente donnée par getLocalHost(), même si cette machine est derrière un firewall.
Exemple d'utilisation de getLocalHost()
(NomLocal.java), cette applet affiche
le nom de votre machine suivi de son numéro IP :
Sur un client récent, ce problème a disparu, vous verrez apparaître localhost/127.0.0.1
Forger est quasiment identique, avec un message un peu plus long. Elle tente de faire croire qu'elle a été envoyée depuis java.sun.com, mais un petit coup d'oeil à l'entête complet révèle son origine.
-
PenPal.java
update (C shell script) - Forger.java
Plus problématique, la gestion des Threads en java 1.02 permet à un thread de remonter dans l'arbre des threads jusqu'au thread parent. AppletKiller utilise cette faille pour tuer tous les threads présents.
L'applet suivante affiche le thread courant ainsi que ses groupes
parents, puis recherche l'ensemble des threads
(ThreadObserver.java):
Le problème est ici lié au fait qu'il n'y a aucun contrôle sur les interactions à l'intérieur de la machine java. Il semble cependant que Netscape 3.01 ne permet pas d'accéder librement aux threads.
ScapeGoat abuse de la méthode showDocument pour charger indéfiniment une page.
Applications hostiles
Le problème posé par les applications est très différent, Java étant utilisé comme n'importe quel autre langage, il a évidemment accès à l'ensemble des ressources de la machine.
Il est ridicule de considérer que l'application suivante est un problème de sécurité lié à Java : Elle se contente d'écrire un script et de l'exécuter. Ce programme ne marche que sous UNIX, et le problème est directement lié à la puissance du shell, non à celle de java.
L'application Dupe.class réécrit Dupe.java lorsqu'on l'exécute. Ce qui présente un intérêt assez limité.
Hijacker place un fichier main.class afin qu'il remplace celui du compilateur javac de sun. Ceci pourrait être utilisé par un virus de type cheval de Troie. Il faut cependant remarquer que sur tout système d'exploitation évolué les logiciels installés ne sont modifiables que par l'administrateur.
PublicEnemy met en lumière un problème certain de Java : il est relativement facile de patcher le bytecode. Cette application modifie des fichiers .class en changeant les droits d'accès aux attributs.
Dans le même style, Attacker modifie la classe Beginner afin qu'elle parte en boucle infinie.
Plus évoluée, la classe Mutator se modifie elle-même, ou plus exactement modifie le fichier .class associé. (Mutator1 est adapté à java 1.1).
Enfin, une dernière application, certainement la plus intéressante : HoseMocha, qui permet d'empêcher la décompilation par mocha. Elle ajoute une instruction pop après le return de chaque méthode, ce qui fait planter mocha. Cependant, il semble que cela empêche aussi certains compilateurs JIT de fonctionner correctement.
Pour d'autres renseignements sur la sécurité en Java, vous pouvez consulter la FAQ de Sun.
N'hésitez pas à m'envoyer vos commentaires, précisions, suggestions, afin de complèter cette page.
